╘HE ╟┼╧╙ CONVERT PROGRAM IS USED TO CONVERT ╟┼╧╙ ╓╠╔╥ AND ╙┼╤ STRUCTURE FILES TO ├OMMODORE ╙┼╤ STRUCTURE FILES. ╫ITHIN THE ├OMMODORE ╙┼╤ FILE WHICH IS CREATED, ALL OF THE ╟┼╧╙-RELATED INFORMATION ABOUT THE FILE IS CONTAINED. ╘HIS INCLUDES THE FILE'S:
- DIRECTORY ENTRY
- HEADER BLOCK
- INDEX TABLE (IF FILE IS ╓╠╔╥)
- DATA BLOCKS
├ONVERT ALSO WILL CONVERT THESE "╟┼╧╙ FORMAT IN ├OMMODORE ╙┼╤" FILES BACK TO THEIR ORIGINAL FORM.
╫HETHER ├ONVERT IS PROCESSING A ╟┼╧╙ ╓╠╔╥ OR ╙┼╤ FILE, THE FIRST TWO BLOCKS OF THE RESULTING ├OMMODORE ╙┼╤ FILE CONTAIN THE SAME INFORMATION:
BLOCK 1: BYTES 0 AND 1 CONTAIN STANDARD
NEXT TRACK AND SECTOR POINTERS
(╬╘╙)
BYTES 2 TO 31 CONTAIN THE
FILE'S DIRECTORY ENTRY, WITH
THE FILE'S ORIGINAL NAME AND
TIME STAMP.
BLOCK 2: BYTES 0 AND 1: ╬╘╙ POINTER
BYTES 2 TO 255: BYTES 2 TO 255
OF THE FILE'S HEADER BLOCK.
╫HEN CONVERTING ╟┼╧╙ ╙┼╤ FILES, THE REST OF THE BLOCKS IN THE RESULTING ├OMMODORE ╙┼╤ FILE ARE THE DATA BLOCKS FROM THE ╟┼╧╙ ╙┼╤ FILE.
BLOCKS 3, 4 ETC:
BYTES 0 AND 1: ╬╘╙ POINTER
BYTES 2 TO 255: BYTES 2 TO 255
OF BLOCK FROM ORIGINAL ╟┼╧╙
╙┼╤ FILE.
LAST BLOCK:
BYTE 0 = 0
BYTE 1 = POINTER TO LAST BYTE
USED IN THIS BLOCK (=$02 TO
$FF)
╫HEN CONVERTING ╟┼╧╙ ╓╠╔╥ FILES, THE THIRD BLOCK IN THE RESULTING ├OMMODORE ╙┼╤ FILE CONTAINS AN INDEX TABLE FOR THE FILE:
BLOCK 3: BYTES 0 AND 1: ╬╘╙ POINTER
BYTE 2: NUMBER OF BLOCKS IN
╓╠╔╥ RECORD #0
BYTE 3: NUMBER OF BYTES IN
LAST BLOCK OF RECORD #0
BYTES 4,5: # BLOCKS/BYTES
IN RECORD #1
...AND SO ON UNTIL:
BYTES 254 AND 255: NUMBER OF
BLOCKS/BYTES FOR RECORD#126
╔F ONE OF THE BLOCK/BYTE PAIRS IS (0,0), THEN THE RECORD DOES NOT EXIST. ╔F A PAIR IS ($00,$FF) THEN THE RECORD IS EMPTY. ╘HE REMAINING BLOCKS IN THE ├OMMODORE ╙┼╤ FILE CONTAIN ALL OF THE ╓╠╔╥ RECORDS, APPENDED END-TO-END, STARTING WITH THE FIRST EXISTING RECORD (USUALLY RECORD #0). ┴DDING UP ALL OF THE "NUMBER OF BLOCKS" ENTRIES IN THE THIRD BLOCK WILL GIVE YOU THE TOTAL NUMBER OF BLOCK WHICH REMAIN.
╘HUS IF THE ╓╠╔╥ FILE HAS TWO BLOCKS IN RECORD #0, ONE BLOCK IN RECORD #4, AND NULL POINTERS (NO BLOCKS) FOR ALL OTHER RECORDS, THEN THE RESULTING ├OMMODORE ╙┼╤ FILE WILL CONTAIN:
┬LOCK 1: DIRECTORY ENTRY
┬LOCK 2: FILE HEADER
┬LOCK 3: BLOCKS/BYTES PER RECORD
TABLE
┬LOCK 4: BLOCK #1 OF RECORD #0
┬LOCK 5: BLOCK #2 OF RECORD #0
┬LOCK 6: BLOCK #1 OF RECORD #4
╬OTE THAT THE CONVERSION PROCESS DOES NOT CREATE A NEW FILE, IT SIMPLY MODIFIES THE EXISTING ╟┼╧╙ ╓╠╔╥ OR ╙┼╤ FILE SO THAT IT CONFORMS TO THE FORMAT OF A ├OMMODORE ╙┼╤ FILE. ╒SING A ╟┼╧╙ ╓╠╔╥ FILE AS AN EXAMPLE, THIS PROCESS INVOLVES:
1) ├REATING A NEW BLOCK TO CONTAIN THE FILE'S DIRECTORY ENTRY, CHANGING THE EXISTING DIRECTORY ENTRY SO THAT THE POINTER TO THE FILE'S FIRST BLOCK NOW POINTS TO THIS NEW BLOCK. ╘HE ╬╘╙ POINTER IN THIS NEW BLOCK WILL POINT TO THE FILE'S EXISTING HEADER BLOCK.
2) ├HANGING THE ╬╘╙ POINTER IN THE BLOCK CONTAINING THE FILE HEADER SO THAT IT POINTS TO THE FILE'S INDEX TABLE BLOCK.
3) ├HANGING THE FILE'S INDEX TABLE BLOCK SO THAT IT HAS ACCURATE "NUMBER OF BLOCKS/BYTES" INFORMATION FOR EACH RECORD. ┴LSO, THE ╬╘╙ POINTER IN THIS BLOCK IS ALTERED TO POINT TO THE FIRST BLOCK OF THE FIRST RECORD WHICH EXISTS.
4) ├HANGING THE ╬╘╙ POINTERS IN THE FIRST AND LAST BLOCKS OF EACH RECORD, SO THAT THE RECORDS ARE APPENDED INTO A STRING OF BLOCKS.
┴LSO, THINK ABOUT THE REVERSE PROCESS. ├ONVERT WILL TAKE A ├OMMODORE ╙┼╤ FILE WHICH COMPLETELY DEFINES A ╟┼╧╙ ╓╠╔╥ OR ╙┼╤ FILE AND WILL CONVERT IT TO THE CORRECT STRUCTURE. ╙OFTWARE DEVELOPERS MAY FIND THIS USEFUL; IF YOU ARE USING A STANDARD ├OMMODORE ASSEMBLER WHICH CREATES ├OMMODORE ╙┼╤ FILES, THEN IF THE DATA IS SET UP RIGHT, ├ONVERT CAN BE USED TO TURN THE ├OMMODORE ╙┼╤ FILE INTO A RUNNABLE ╟┼╧╙ ╓╠╔╥ OR ╙┼╤ APPLICATION! ╫E WILL POST A NOTE IN THE FUTURE ABOUT HOW TO DO THIS.
┴╨╨┼╬─╔╪ ├ (╨432) ├╧╥╥┼├╘╔╧╬╙...
╘HANKS FOR ╩PP AND ═IKE╘22 FOR ALERTING ME TO SOME ERRORS ON ╨432 OF THE ╨ROG ╥EF ═ANUAL:
─ONE╫ITH╔╧ SHOULD READ $C25F ├OPY╙TRING SHOULD READ $C265
─┼╙╦ ┴├├┼╙╙╧╥╔┼╙ ╔╬ ┴╨╨╠╔├┴╘╔╧╬╙
╘HIS NOTE IS FOR PEOPLE WRITING APPLICATIONS WHICH ALLOW THE USER TO RUN DESK ACCESSORIES.
═OST ╟┼╧╙ APPLICATIONS THAT HAVE BEEN WRITTEN ARE ╓╠╔╥ MODULE SWAPPING APPLICATIONS, AND SO THE DISK CONTAINING THE APPLICATION MUST ALWAYS BE IN ONE OF THE ACTIVE DRIVES. ╘HE CONVENTION FOR PLACEMENT OF DESK ACCESSORIES IS THAT THEY MUST BE ON THE APPLICATION DISK. ╘HIS WAY, THE ─┴S WHICH APPEAR IN THE APPLICATION'S ╟┼╧╙ MENU ARE ALWAYS ACCESSIBLE. ┴PPLICATIONS OF THIS TYPE WHICH ALLOW THE USER TO LOAD DATA FROM THE OTHER DRIVE MUST KEEP TRACK OF WHICH DRIVE IS THE APPLICATION DRIVE. ╞OR EXAMPLE, ASSUME THE APPLICATION DISK IS IN DRIVE ┴ AND THE DATA DISK IS IN DRIVE ┬. ╫HEN THE APPLICATION IS RUN FROM THE DESK╘OP, ONE OF THE FIRST THINGS IT DOES IS TO READ THE DISK'S DIRECTORY, GRABBING THE NAMES OF THE ─┴S ON THAT DISK AND STUFFING THEM INTO THE ╟┼╧╙ MENU DEFINITION TABLE. ╘HEN WHEN THE USER HAS OPENED A DATAFILE WHICH IS ON THE DISK IN DRIVE ┬, AND HE SELECTS A ─┴ FROM THE MENU, THE APPLICATION MUST CALL ╧PEN─ISK TO OPEN DRIVE ┴ TO RUN THE ─┴. ╫HEN THE ─┴ FINISHES, THE APPLICATION MUST CALL ╧PEN─ISK TO RE-OPEN THE DATA DISK IN DRIVE ┬. ╔F THE SYSTEM ONLY HAS ONE DRIVE, THEN THERE IS NO PROBLEM BECAUSE THE DISK IN DRIVE ┴ CONTAINS THE APPLICATION, THE ─┴S, AND THE DATAFILE; NO DRIVE SWITCHING IS REQUIRED WHEN RUNNING ─┴S.
╞OR APPLICATIONS WHICH RUN ENTIRELY RESIDENT IN MEMORY (NEVER SWAPPING MODULES) YOU MIGHT BE TEMPTED TO ALLOW THE USER TO REMOVE THE DISK ON A ONE-DRIVE SYSTEM AND INSERT A DIFFERENT DATA DISK. ┴PPLICATIONS SUCH AS THE ╔CON ┼DITOR ALLOW THIS. ┬UT BE SURE THAT IF YOU ALLOW THIS CAPABILITY, THAT WHEN THE ─┴ IS SELECTED ┴╬─ THE APPLICATION DISK HAS BEEN REMOVED, YOU MUST EITHER 1) NOT ALLOW THE ─┴ TO RUN, OR 2) PUT UP A DIALOG BOX REQUESTING THAT THE APPLICATION DISK BE INSERTED SO THAT THE ─┴ CAN RUN.
═┴├╥╧╙ ╞╧╥ ╥┼╞┼╥┼╬├┼ ═┴╬╒┴╠
┘OU GUYS ARE ABSOLUTELY RIGHT! ╘HE ╥EFERENCE ═ANUAL DOES NOT HAVE A PAGE DESCRIBING THE MACROS WE USE IN THE SOURCE LISTINGS. ╚ERE ARE THE 5 MOST POPULAR:
*** ╠OAD┬ ***
╠OAD┬ IS USED TO STUFF A CONSTANT VALUE INTO A SINGLE-BYTE MEMORY LOCATION.
.MACRO ╠OAD┬ ADDR,VALUE
LDA #VALUE
STA ADDR .ENDM
SAMPLE USAGES:
╠OAD┬ R0╚,#52
╠OAD┬ $0001,#$35
╠OAD┬ MOUSE┘╨OSITION,#34
*** ╠OAD╫ ***
╠OAD╫ IS USED TO STUFF A WORD CONSTANT INTO A WORD (TWO SEQUENTIAL BYTES) MEMORY LOCATION.
.MACRO ╠OAD╫ ADDR,VALUE
LDA #[VALUE
STA ADDR
LDA #]VALUE
STA ADDR+1 .ENDM
╬OTE THAT THE [ CHAR IS USED TO GET THE LOW BYTE VALUE OF A WORD CONSTANT, AND ] IS USED TO GET THE HIGH BYTE VALUE...
╙AMPLE USAGE: ╠OAD╫ R0,#$4000
*** ═OVE┬ ***
═OVE┬ IS USED TO COPY DATA FROM ONE MEMORY LOCATION TO ANOTHER.
.MACRO ═OVE┬ SOURCE,DEST
LDA SOURCE
STA DEST .ENDM
╙AMPLE USAGE:
═OVE┬ R0╚,R2╚ ;SET R2╚=R0╚
*** ═OVE╫ ***
╙AME AS ═OVE┬, BUT COPIES A WORD.
.MACRO ═OVE╫ SOURCE,DEST
LDA SOURCE
STA DEST
LDA SOURCE+1
STA DEST+1 .ENDM
╨╥╟╘╧╟┼╧╙ (├HAPTER 3) ├ORRECTIONS:
╙EVERAL OF YOU HAVE NOTICED THAT THE ╨╥╟╘╧╟┼╧╙ UTILITY DESCRIBED IN CHAPTER 3 DOES NOT WORK. ╫ITH THE FOLLOWING CORRECTIONS, YOU SHOULD HAVE NO PROBLEM WITH IT.
╧N PAGE 48, REPLACE THE "PSECT 400" WITH:
.PSECT $304 ;╘HE FILEHEADER DOES NOT ACTUALLY START AT $304; THIS PSECT IS NECESSARY SO THAT THE FILEHEADER OCCUPIES THE FIRST 252 BYTES OF THE ╨╥╟ FILE WHICH YOUR ASSEMBLER CREATES.
╘HE COMMENTS BELOW "╞ILE╚EADER" SHOULD READ:
;╘HE FIRST FOUR BYTES OF THE FILEHEADER WILL BE WRITTEN TO THE HEADER BLOCK BY THE ╨╥╟╘╧╟┼╧╙ BASIC PROGRAM DURING CONVERSION. ╞OR YOUR INFORMATION, THE FIRST FOUR BYTES WILL CONTAIN:
